WebSecurity#ignoring should not be warned #17316
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For years Spring Security exposes method WebSecurity#ignoring but pollutes logs with false positive warning.
Let's analyze my case.
Spring Security authorizes by default access to actuator endpoints and that is OK.
However, nowadays applications are often cogs in machine and is important to distinguish application responsibily and cloud/Kubernetes/service mesh responsibility
Actuator endpoints, identical for hundreds application, should be protected by Kubernetes, not by application. It is not application responsibility
Application responsibility is configuring business endpoint access
See this snippet
```
httpSecurity.authorizeHttpRequests ( configurer -> configurer
.requestMatchers("/illness/covid/statistics/2021").permitAll()
.requestMatchers("/illness/myillness").authenticated()
---
webSecurity.ignoring().requestMatchers("/actuator")
```
It clearly shows that application responsibily is expose publicly world statistics by restrics access to private data
And, what more important, it clearly shows that actuator access IS NOT application responsibilty
I think it is more readable than
```
httpSecurity.authorizeHttpRequests ( configurer -> configurer
.requestMatchers("/illness/covid/statistics/2021").permitAll()
.requestMatchers("/actuator").permitAll()
.requestMatchers("/illness/myillness").authenticated()
```
Conclusion:
I want remove warning WebSecurity#ignoring because I want promote clear, straightforwad, readable code
spring-projects-issues
added
the
status: waiting-for-triage
|
Thank you for reaching out. The warning exists because Given all of this, we are not planning on removing the warning. |
rwinch
added
status: declined
|
Thank for explanation. But I still think that Security API does not follow current coexistence business endpoints and infrastructure (actuator) endpoints. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For years Spring Security exposes method WebSecurity#ignoring but pollutes logs with false positive warning.
Let's analyze my case.
Spring Security authorizes by default access to actuator endpoints and that is OK.
However, nowadays applications are often cogs in machine and is important to distinguish application responsibility and cloud/Kubernetes/service mesh responsibility.
Actuator endpoints, identical for hundreds application, should be protected by Kubernetes, not by application.
Application responsibility is configuring business endpoint access
See this snippet
It clearly shows that application responsibily is expose public statistics and restrict access to private data.
And, what more important, it clearly shows that actuator access IS NOT application responsibility
I think it is more readable than
Conclusion:
I want remove warning WebSecurity#ignoring because I want promote clear, straightforwad, readable code.